The `update-changelogs` workflow is designed to run automatically and
manually (in response to a `metamaskbot` comment on a release PR).

Currently, the manual run succeeds, but the automatic run does not. We
use the `default-branch` environment for commands in this workflow as we
need a tightly-scoped token that to push to the PR branch. The problem
is that our use of the `pull_request` event for automatic runs and our
use of the `default-branch` environment conflict with each other and
trigger our branch protection rules (the `default-branch` is scoped to
the `main` branch, not pull request branches).

To fix this, instead of `pull_request`, we use the `pull_request_target`
event. This event runs against the default branch, and so it should
match the same scope as the `default-branch` environment and satisfy the
branch protection rules we have in place. However, as this is a
dangerous event — [GitHub recommends against
it](https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/secure-use#mitigating-the-risks-of-untrusted-code-checkout)
— we have to be careful not to allow commands to run directly against a
pull request branch.

So, we modify the workflow to follow this plan:

1. Check out the PR base branch (usually `main`)
2. Set up Node, install Yarn + dependencies
3. Overlay changelogs from the PR branch
4. Create a temporary commit to clear the working index
5. Update changelogs with dependency bumps as needed
6. Make a new commit
7. Check out the pull request branch completely (overwriting the base
branch)
8. Cherry-pick the new commit on to it
9. Push the pull request branch
10. Done!

## Explanation

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

https://consensyssoftware.atlassian.net/browse/WPC-997

## Checklist

- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them




<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Medium risk because it changes a privileged `pull_request_target`
workflow that checks out refs and pushes commits to PR branches;
misconfiguration could create a security or branch-protection bypass.
> 
> **Overview**
> Updates `.github/workflows/update-changelogs.yml` to trigger on
`pull_request_target` (instead of `pull_request`) so the workflow runs
against `main` while using the `default-branch` environment/token.
> 
> Reworks the changelog update flow to **avoid running untrusted PR
code**: check out the merge base, detach `HEAD`, overlay only
`**/CHANGELOG.md` from the PR, commit those as a temporary baseline, run
`yarn changelog:validate --checkDeps --fix` with `continue-on-error`,
then commit any resulting changelog fixes and **cherry-pick/push** that
commit onto the PR head SHA/ref.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
68a9155. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

## Explanation

**Current state**

`PasskeyController` verifies registration and authentication with
`requireUserVerification: true`, so the server expects the WebAuthn
**user verification (UV)** flag on assertions. For enrollment-time
`get()` options, `generatePostRegistrationAuthenticationOptions` already
used `userVerification: 'required'`, but
**`generateAuthenticationOptions`** (unlock / enrolled passkey) still
used `userVerification: 'preferred'`. With `'preferred'`, the client may
allow authenticators to skip UV, producing assertions **without** UV
that the server then rejects—wasted ceremonies and confusing failures.

**Solution**

Set `userVerification: 'required'` on the object returned by
`generateAuthenticationOptions`, matching the post-registration path and
server verification. Add a unit test that enrolled flows emit
`'required'`. Document the fix in
`packages/passkey-controller/CHANGELOG.md` under the appropriate
**Unreleased** or release section.

**Not obvious**

This is a client/server **hint alignment** fix, not a new API. Behavior
may be stricter at `navigator.credentials.get()` (UV required), which
matches what verification already enforced.

**Scope**

Changes are limited to `@metamask/passkey-controller` (implementation,
tests, changelog). No dependency upgrades.

## References

- Related: [#8696](#8696) *(replace
or extend with your issue/PR links)*

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate *(optional: JSDoc on
`generateAuthenticationOptions` if you want to mention UV)*
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them *(N/A—patch-level behavior fix, no
breaking API changes)*

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk release bookkeeping only (version bumps and changelog
updates) with no functional code changes in this diff.
> 
> **Overview**
> Updates release metadata by bumping the root monorepo version to
`965.0.0` and `@metamask/passkey-controller` to `2.0.1`.
> 
> Adds a `passkey-controller` `2.0.1` changelog entry documenting
stricter WebAuthn user verification requirements and the
`generateAuthenticationOptions` alignment to `userVerification:
'required'`, and updates the changelog compare links accordingly.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
8891f9b. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->